[レポート] 「コンテナと Kubernetes のベストプラクティス TOP 5」を New Relic 的に聞いてきた #CON307 #reinvent

re:Invent 2019 の標題の Chalk Talk セッションを聞いてきました。普通にコンテナと k8s のベストプラクティスの紹介でしたが、それを New Relic が扱うとどうか、という視点のセッションでもありました。ここではその New Relic 的な視点にフォーカスを当ててご紹介します。

セキュリティ製品特集

#k8s

#Kubernetes

#New Relic

#監視サービス

#Amazon EKS

渡辺聖剛

2019.12.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

CON307 Top 5 container and Kubernetes best practices

本セッションについては既に城岸がレポートをしていますので、そちらもあわせてご覧ください。

[レポート] コンテナおよび Kubernetes のベストプラクティストップ 5 #reinvent #CON307 ｜ Developers.IO

概要（抄訳）

コンテナや Kubernetes (k8s) のようなテクノロジーは、あなた方のソフトウェアのデプロイプロセスを簡単で高速なものにします。一方で、新しい開発ツールやオーケストレーション方法は、マネジメントやモニタリングの文脈において、従来の環境から大きく変化しています。（略）
このセッションでは、あなたが AWS 上にマイグレートするだろう新しいアプリケーションの、効率と品質を保証するためのベストプラクティスを紹介します。このプレゼンテーションは APM パートナーの New Relic 社がお送りします。

動画

スピーカー

Grace Andrews
Solutions Consultant , New Relic

内容

このセッションでは、k8s とコンテナの話をする
- コンテナを使ってるひとは？ -> 会場で結構な数が手を挙げる
- k8s とコンテナにとってのオブザーバビリティ（可観測性）の話をする
Kubernetes は
- 素早く動かすことを助ける
- コスト最適化している
- ポータビリティがある
ベストプラクティス
- コンテナイメージを小さく保つ
- 名前空間のレバレッジ
- ヘルスチェックを設定する
- （k8s 定義の） resources: requests: と limits: を設定する：多段アラートを設定する
- 問題のコンテキスト（背後関係）を理解する

コンテナイメージを小さく保つ

Why?
- ビルドタイムと pull タイムを速くする
- 脆弱性が入る余地を少なくする
- ストレージ消費量を少なくする
- イメージの pull とコールドスタートを高速化
How?
- アプリケーションが必要としているものを認識する
- 最適なベースイメージを選択する
  - 同じ node.js の Dockerfile で
  - Base image -> 700MB
  - Alpine -> 65MB
- 必要ないリソースを削除する
  - package + files
Docker build cache を効かせる
- 各イメージで共通なものをまとめることでキャッシュの効きを最大限に生かす
New Relic では
- Kubernetes cluster explorer を確認
- PENDING ステータスの時間を削減する

名前空間のレバレッジ

「名前」とは？

k8s の可観測性 - 名前空間の有意性
名前空間もリソース = リソースを割り当てるようにネームスペースも割り当てる
Why?
- 管理性とセキュリティの向上
  - 異なるチームで k8s のリソースを独立させる
- 性能の向上
  - k8s API はオブジェクトの似たようなセットの中で動作する
How?
- 設定ファイル (YAML) を修正
- YOUR_CLUSTER_NAME をアップデート
- kubectl apply
New Relic では
- Kubernetes cluster explorer
- 名前空間毎にクラスタが表示される
- 表示された ALERTING ステートの pod をドリルダウン
- そのためにも、適切な名前付けをしておくことが大切

ヘルスチェックを設定する

health checks
- Readiness probes
  - そのアプリケーションはトラフィックを受ける準備ができているのかどうか？
- Liveness probes
  - そのアプリケーションが生きているかどうか？
Why?
- より迅速なトラブルシューティングとイシューの解像度をあげる
- クラスタ内でおきる全てのイベントを確認
- スケーリングのような特定のイベントを追跡 (Track) する
How?
- YAML ファイルに固有のプローブを設定
  - readinessProbe
  - livenessProbe
- 忘れずにinitialDelaySecondsを設定
- kubectl apply
New Relic では
- Event 検索画面でreadiness livenessキーワードを引っかける
- そのキーワードに関連する一連のイベントが一覧・追跡できる

resources: requests: と limits: を設定する

Requests
- コンテナが取得できると保証されているリソース量
Limits
- そのコンテナが確保できるリソース量の限界値
Why?
- リソース不足は pod を不安定にし、最悪落とされる
- CPU Limit 超えた pod > 止まる
- メモリ Limit 超えた pod > 落とされる
- リソース確保ができない pod は PENDING ステート（起動しない）
適切でないサイズの requests はスケジューリングの問題を起こす可能性あり
- ノードの最大の値を超えるリソースを要求する pod はスケジュールすらされない
How?
- limit と requests を指定する
- kubectl apply
- kubectl describeで requests と limits のリスト表示ができる
New Relic では
- Kubernetes cluster explorer
- 任意の pod をクリック -> request, limit と現在の使用量がグラフで確認できる

問題のコンテキストを理解する

可視性を上げる - クラスタで何が起きているか？
理解度を上げる - その pod は正常か？
安定性を上げる - いま使っているホストは妥当か？
New Relic では
- Kubernetes logging - 問題を理解する
- Kubernetes cluster explorer
Why?
- 環境のふるまいについてのコンテキストを多く出力する
- 障害発生時により早く解決させるため
How?
- k8s にログ出力プラグインをインストールする
- ライセンス情報をアップデートする
- kubectl apply -> インジェスト開始